\subsection{Prototype Implementation}
\textbf{Creation}\\
There are two types of creation in the CyberOrgs system: CyberOrg creation and actor creation. CyberOrg creation method is called only once by the GUI or user program to create the first CyberOrg in the system; future CyberOrg creations happen as a result of invocation of the isolate primitive. Actor creation method is called by existing actors to create other actors or by the CyberOrg constructor in order to create the facilitator actor \cite {cyber}.\\
\\
\textbf{CyberOrg creation :}
\begin{verbatim}
CyberOrg createCyberOrg(long ticks, long 
ticksrate, long eCash, String facilitatorClass, 
Object[] args)
\end{verbatim}

where \emph{ticksrate} is the rate of processor time that the new CyberOrg would receive with respect to the CyberOrg in one scheduling cycle; \emph{eCash} is the number of eCash units that are used for buying
processor resource from host CyberOrg; \emph{facilitatorClass} and \emph{args} identify the facilitator actor class for the CyberOrg and the arguments for creating such a facilitator actor \cite {cyber}.\\
\\
\textbf{Actor creation:}
\begin{verbatim}
ActorName createActor(ActorName creator, 
String actorClass, Object[] args)
\end{verbatim}
where \emph{creator} is the unique name of the creator; \emph{actor-Class} and \emph{args} specify the class of the actor being created and the arguments used in the actor constructor. This method is used by one actor to create another actor\cite {cyber}.
\begin{verbatim}
ActorName createActor(CyberOrg host,
String facilitatorClass,  Object[] args)
\end{verbatim}
where \emph{host} identifies the creating CyberOrg; \emph{facilitator-Class} identifies the actor class of the facilitator and \emph{args} specify the arguments to be used in constructing the facilitator actor. This is used by the CyberOrg constructor at the time of creation of a CyberOrg to create a facilitator actor.\\
\\
\textbf{CyberOrgs Primitives:}\\
Primitive CyberOrgs operations are called by the facilitator actor of the CyberOrg.\\
\\
\textbf{Isolation:}
\begin{verbatim}
CyberOrg isolate(long eCash, 
ActorName[] actors, Contract newContract)
\end{verbatim}

where \emph{eCash} is the amount of eCash that is given to the newly created CyberOrg; \emph{actors} is an array of existing actors that will be isolated into the new CyberOrg; \emph{newContract} is the contract imposed on the new CyberOrg and its host CyberOrg which specifies the ticks and ticks rate that the new CyberOrg receives, as well as the cost of the resources in terms of eCash payments to be made.\\
\\
\textbf{Assimilation: }
\begin{verbatim}
CyberOrg assimilate() 
\end{verbatim}
This primitive will cause assimilation of the CyberOrg into its host. \\
\\
\textbf{Migration:}
\begin{verbatim}
void migrate(ActorName facActorOfDestCyberOrg,
Contract newContract)
\end{verbatim}
where \emph{facActorofDestCyberOrg} is the name of facilitator actor in the destination CyberOrg which serves as the CyberOrg's name; \emph{newContract} is the negotiated contract between the migrating CyberOrg and the intended host. 
\\
\\
\textbf{Negotiation}\\
Before migration, a CyberOrg needs to negotiate a contract with a prospective host. The negotiation is initiated by the facilitator actor of the CyberOrg interested in migrating by a call of the negotiation primitive\cite {cyber}.
 Negotiation:
\begin{verbatim}
Contract negotiate(ActorName 
   	destFacilitatorActor)
\end{verbatim}
Here \emph{destFacilitatorActor} is the facilitator actor of the prospective future host CyberOrg.

\textbf{CyberOrgs Directory Manager (CDM):} This directory manager contains information about all CyberOrgs. In response to request from broker, it returns a list of potential resources. Any resource provider can register itself in CDM.

\textbf{Game Directory Manager (GDM):} GDM contains the information of CyberOrgs that are serving as game servers. The difference between GDM and CDM is in GDM a resource is registered through negotiation process. This negotiation happens between the game provider and resource provider. The final contract is also put into the game directory manager. Once a resource is registered in GDM it is considered to be a live game server.

The following code fragments allow registering, deregistering and search for potential CyberOrgs :
\begin{verbatim}
public void register(CyberOrgTuple p_ctTuple) 
{
  	// Register CyberOrgs in GDM or CDM
  	m_pubTSpace.write(p_ctTuple);
  	System.out.println(p_ctTuple.getDestination()
  	+ " " + p_ctTuple.getId() + " " 
  	+ p_ctTuple.getFacClassName()+ " " 
  	+ p_ctTuple.getContract());
}
           
public void deregister(CyberOrgTuple p_ctTuple)
{
  	// Removes an CyberOrg tuple in this DM.
  	// p_ctTuple a tuple data to be removed in 
  	// this DM.
  	m_pubTSpace.removeAll(p_ctTuple);
}

public CyberOrgTuple[] searchAll(Contract 
   	contract) throws Exception 
{
  	// Search all CyberOrgs which contract match 
  	// with in GDM
  	return m_pubTSpace.searchAll(contract);   
}


\end{verbatim}

Here CyberOrgTuple is an Object that encapsulates necessary information such as the \emph{ip address} and the \emph{facilitator actor} of a CyberOrg.

\textbf{Resource Provider (RP): }Resource provider can send request to register its resources to CDM through Broker.
\begin{verbatim}
ActorMessage am_reg = new ActorMessage(
   	myPlatform.getActorNameOfPlatform(),
   	broker, "registerToCDM", argsreg, false);
myPlatform.sendMessage(am_reg);
\end{verbatim}


\textbf{Game Provider (GP): }The Game Providers are the publishers or developers of the game. They search for more resources when it is required by the server. Initially Game Provider sends request to broker to find out what are the potential resources available. The broker receives this request, in response it returns a list of CyberOrgs that are currently registered in CDM. Upon receiving this list game provider tries to propose a contract to each of the CyberOrgs from the list and keep doing this until a successful negotiation is made. This CyberOrg is now in GDM and removed from CDM.\\
\\
\\
\\
\begin{verbatim}
public void searchAndReg(Contract contract)
{
  	// Through this got all the list of
  	// potential resources from broker.
  	tupleList = (CyberOrgTuple[]) call(broker, 
   	"getPotentialResourceList", 
   	this.getContract());
}
public boolean negotiate(CyberOrgTuple 
   	CyberOrgTuple)
{
  	// Negotiation with different CyberOrgs 
  	// from the list given by broker.
  	finalContract = (Contract) call(remoteFaci, 
   	"negotiate", this.getActorName(), 
   	this.getContract());
}
public void registerGDM(CyberOrgTuple 
   	CyberOrgTuple)
{
  	// Contract is signed within GP and 
  	// CyberOrgs and it got registered in GDM.
  	send(broker, "registerToGDM", CyberOrgTuple);
}
\end{verbatim}



\textbf{Game Client (GC):} A Game Client initially requests the broker for the available services that are provided by game provider. The broker presents the service list to the player and allows him to  select appropriate services according to his requirements. This selected services are sent back to broker for calculating the cost involved in those services. The Broker than searches in the GDM for resource that match the price tag. This search result is returned to the game client. Now game player can select a particular server from this list and get connected to the chosen server. During this connection phase, game provider is paid for service. We have not fully implemented Game Client yet.

\textbf{Broker:} Broker provides different services to different parties. For game provider it provides information on resources that are registered in CDM. On the other hand, every resource is register to CDM through broker. Broker receives the request for registration from resource provider.\\
\begin{verbatim}
public void registerToCDM(CyberOrgTuple 
   	CyberOrgTuple)
{
  	// Regsiter request to CDM through broker
  	send(this.getAnCybDM(), 
   	this.getRegMethodname(), CyberOrgTuple);
}

public CyberOrgTuple[] 
   getPotentialResourceList(Contract contract) 
{
  	// Returns the list of all potential resources.
  	CyberOrgTuple[] tempList = 
   	(CyberOrgTuple[]) call(this.getAnCybDM(),
   	searchMethodName, contract);
  	return tempList;
}
\end{verbatim}
\\
\begin{verbatim}
public void registerToGDM(CyberOrgTuple 
   	CyberOrgTuple) 
{
  	// Register to GDM through broker
  	send(this.getAnGameDM(), 
   	this.getRegGDMMethodname(), CyberOrgTuple);
}
\end{verbatim}

We have developed an interface to launch the game server (Quake-II) from java application. This interface was written using Java Native Access (JNA). It enables us to call native Windows API and control the recourses of the server (As we used a windows based Quake II server).\\

\textbf{Creating a process (starting the server):}
\begin{verbatim}
kernel32.CreateProcessW(new WString(
   	"path\\quake2.exe"),
   null,
   null,
   null,
   false,
   CREATE_SUSPENDED|CREATE_BREAKWAY_FROM_JOB,
   null,
   new WString("path"),
   STARTUPINFO,
   pi);
\end{verbatim}

Here \emph{kernel32} is an object to access native kernel32 library and \emph{STARTUPINFO} is an instance of the STARTUPINFO structure that is initialized with process startup arguments.

\textbf{Creating a job and assigning process to the job:}

\begin{verbatim}
Pointer hjob = kernel32.CreateJobObjectW(
   	sa, new WString("GameServer"));
if(!kernel32.AssignProcessToJobObject
   	(hjob, pi.hProcess))
  	System.out.println("couldnt assign process 
   	to job");
\end{verbatim}

\textbf{Set job information (Resource Allocation ):}
Following code fragment describes how to allocate a process for 1000 sec.
\begin{verbatim}
Ren.JOBOBJECT_BASIC_LIMIT_INFORMATION hp=
   	new Ren.JOBOBJECT_BASIC_LIMIT_INFORMATION();          
hp.LimitFlags = JOB_OBJECT_LIMIT_PROCESS_TIME
   	|JOB_OBJECT_LIMIT_ACTIVE_PROCESS;
hp.PerProcessUserTimeLimit=1000000;
hp.ActiveProcessLimit = 1;
if(!kernel32.SetInformationJobObject(
   	(hjob,JOB_OBJECT_BASIC_LIMIT_INFORMATION, 
   	hp, hp.size()))
{
  	System.out.println("couldnt set job info");
}
\end{verbatim}
